home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / digestv3.zip / V3N7M.TXT < prev    next >
Text File  |  1993-12-07  |  13KB  |  310 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Musician's Digest       Tue, 7 Dec 93  2:30          Volume 3: Issue   7  
  5.  
  6. Today's Topics:
  7.     Custom patches shipped with songs (was Patch Banking Treatise)
  8.                      GUS grannies and their banks
  9.                      GUS Musician's Digest V3 #4
  10.                      GUS Musician's Digest V3 #6
  11.                              MIDI-Through
  12.                    patch banking experiment report
  13.                    Patch banking standards proposal
  14.  
  15. Standard Info:
  16.     - Meta-info about the GUS can be found at the end of the Digest.
  17.     - Before you ask a question, please READ THE FAQ.
  18.  
  19. ----------------------------------------------------------------------
  20.  
  21. Date: Mon, 6 Dec 93 09:14:29 EST
  22. From: "Burns Fisher, VMS Engineering  06-Dec-1993 0914" <fisher@skylab.enet.dec.com>
  23. Subject: Custom patches shipped with songs (was Patch Banking Treatise)
  24.  
  25.  
  26.  
  27. ------------------------------
  28.  
  29. Date: 07 Dec 1993 03:40:14 +0700 (SST)
  30. From: TC <SH7126146@NTUVAX.NTU.AC.SG>
  31. Subject: GUS grannies and their banks
  32.  
  33. Eric,
  34.  
  35. > Here's the trouble with this approach. The application programs would
  36. > have to be modified to 'know' about and handle the .cfg file. Or the
  37. > driver would have to do the work, except the driver doesn't know
  38. > anything about filenames you might be playing. Even if it were 'told'
  39. > explicitly to load a .cfg file, that still means the calling
  40. > applications have to be modified.
  41.  
  42. What you could do in terms of automating the process for GUS grannies,
  43. is this: When you detect any bank switching code in the MIDI file, you
  44. inform the user that such-and-such bank will be used for a new
  45. instrument xxx (which could be embedded as a SysEx command). The user
  46. can elect to have the application overwrite his ULTRASND.INI to install
  47. the instruments in the specified banks, or install the instruments in a
  48. new bank (of his choosing) and change all references in the MIDI file
  49. accordingly, or ignore it.
  50.  
  51. Only GUS aware apps will do this of course. After all, even users of
  52. real synthesizers have to fiddle around too.
  53.  
  54.  tc
  55.  
  56. ------------------------------
  57.  
  58. Date: Sun, 5 Dec 1993 00:58:53 -0500
  59. From: jericho!gord (Gord Wait S-MOS Systems Vancouver Design Center)
  60. Subject: Re: GUS Musician's Digest V3 #4
  61.  
  62. RE: custom patches with midi songs..
  63. I think it would be a good thing to be able to ship songs out 
  64. and include custom patches with them. You can do this now for 
  65. playmidi can't you? IE for a midi file named woof.mid have a
  66. patch config file called woof.cfg that maps in the custom
  67.  pat files? I haven't tried this for a while. It also doesn't
  68. help under windows of course..
  69.  
  70. ------------------------------
  71.  
  72. Date: Mon, 6 Dec 1993 12:55:43 -0500 (EST)
  73. From: Phat H Tran <ptran@sciborg.uwaterloo.ca>
  74. Subject: Re: GUS Musician's Digest V3 #6
  75.  
  76. > Date: 05 Dec 93 17:21:32 EST
  77. > From: "Eric Bell, Howling Dog Systems" <71333.2166@CompuServe.COM>
  78. > Subject: Bank stuff
  79. > 
  80. > Phat writes:
  81. > 
  82. > > Why not have the Windows driver fill GUS RAM from the bottom (0k) up with
  83. > > melodic patches, and from the top (1024k -- or 1016k if 8k is reserved for
  84. > > WAV buffering) down with percussion patches?  This would save having to
  85. > > reload the drum patches each time a new melodic patch was needed.
  86. > 
  87. > This would make more sense, but there is no memory management in the chip at present. This task might be impossible.
  88. >
  89.  
  90. All the memory management is done by the driver, so it can fill memory
  91. however it wants.
  92.  
  93. > > 2.  MidiOutCachePatches should keep track of not only which patches have
  94. > > been cached, but from which bank.
  95. > 
  96. > > 3.  The driver should respond to Controller 0 to keep track of which bank
  97. > > is active for _each_ channel.
  98. > 
  99. > I think this would give us a really excellent and flexible system, but I worry
  100. > about having enough RAM on the board to make use of it to any extent.
  101.  
  102. I don't think RAM is any more a concern with patch banking than without.
  103. Even if we can pick and choose patches from any bank we want for each
  104. channel, are we likely to require any more patches than if we weren't
  105. allowed to switch banks?  I don't think so.  I think patch usage per MIDI
  106. piece would remain in the 20 to 30 instrument range, which 1 MB can 
  107. accomodate very well.
  108.  
  109. Phat.
  110.  
  111. ------------------------------
  112.  
  113. Date: 6 Dec 93 17:44:17 +0100
  114. From: "Alexander Majarek, Sascha, SAM"  <Alexander.Majarek@uibk.ac.at>
  115. Subject: MIDI-Through
  116.  
  117. Thanks again for your replies concerning my questions two weeks ago
  118. (Midi-In, Midi-Volume, Midi-Out, etc. with a digital piano). They
  119. helped me with a lot of problems.
  120.  
  121. One question is remaining: I am sure I have selected MIDI-Through in
  122. PatchMan and have selected the patch in the right window. Anyway:
  123.  ... I get NO sound when I play on my keyboard (and it sends on
  124. CHANNEL 1 !). When I close PatchMan and start Midi-Mon or Winjammer,
  125. I have no problems getting sound out of my gus when I'm touching my
  126. keyboard (the patch which was selected when I closed PatchMan).
  127.  
  128. Any idea what's going wrong there (in PatchMan)
  129.  
  130. Thanks in advance,
  131. SAM
  132.  
  133. *********************************************************************
  134. *Alexander.Majarek@uibk.ac.at * There are 3 ways (fast, sweet, sure)*
  135. *Perthalerg. 1c/11            * for a man to ruin himself:          *
  136. *A-6020 Innsbruck             * 1. Gamblin'   (fast),               *
  137. *AUSTRIA (EUROPE)             * 2. Women      (sweet) &             *
  138. *Tel.: 0043-512-84-26-15      * 3. Computers  (sure)                *
  139. *********************************************************************
  140.  
  141. ------------------------------
  142.  
  143. Date: Mon, 6 Dec 93 10:51:20 +0100
  144. From: f93-maj@nada.kth.se
  145. Subject: patch banking experiment report
  146.  
  147. This is what the Borland C++ 3.1 Multimedia Reference sais about Patch Caching:
  148.  ------------------------------------------------------------------------------
  149.  
  150. midiOutCachePatches
  151.  
  152. Syntax: UINT midiOutCachePatches(hMidiOut, wBank, lpPatchArray, wFlags)
  153.  
  154. This function requests that an internal MIDI synthesizer device preload a specified set of patches. Some synthesizers are not 
  155. capable of keeping all patches loaded simultaneously and must load data from disk when they receive MIDI program change 
  156. messages. Caching patches ensures specified patches are immediately available.
  157.  
  158. Parameters
  159.  
  160. HMIDIOUT hMidiOut
  161. Specifies a handle to the opened MIDI output device. This device must be an internal MIDI synthesizer.
  162.  
  163. UINT wBank
  164. Specifies which bank of patches should be used. To specify caching of the default patch bank, set this parameter to zero.
  165.  
  166. LPPATCHARRAY lpPatchArray
  167. Specifies a pointer to a PATCHARRAY array indicating the patches to be cached or uncached.
  168.  
  169. UINT wFlags
  170. Specifies options for the cache operation. Only one of the following flags can be specified:
  171.  
  172. MIDI_CACHE_ALL
  173. Cache all of the specified patches. If they can't all be cached, cache none, clear the PATCHARRAY array, and return 
  174. MMSYSERR_NOMEM.
  175.  
  176. MIDI_CACHE_BESTFIT
  177. Cache all of the specified patches. If all patches can't be cached, cache as many patches as possible, change the 
  178. PATCHARRAY array to reflect which patches were cached, and return MMSYSERR_NOMEM.
  179.  
  180. MIDI_CACHE_QUERY
  181. Change the PATCHARRAY array to indicate which patches are currently cached.
  182.  
  183. MIDI_UNCACHE
  184. Uncache the specified patches and clear the PATCHARRAY array.
  185.  
  186. Return Value
  187. Returns zero if the function was successful. Otherwise, [stuff deleted]
  188.  
  189. Comments
  190. The PATCHARRAY data type is defined as:
  191. typedef WORD PATCHARRAY[128];
  192. Each element of the array represents one of the 128 patches and has bits set for each of the 16 MIDI channels that use that 
  193. particular patch. The least-significant bit represents physical channel 0; the most-significant bit represents physical channel 15 
  194. (0x0F). For example, if patch 0 is used by physical channels 0 and 8, element 0 would be set to 0x0101.
  195. This function only applies to internal MIDI synthesizer devices. Not all internal synthesizers support patch caching. Use the 
  196. MIDICAPS_CACHE flag to test the dwSupport field of the MIDIOUTCAPS structure filled by midiOutGetDevCaps to see if the 
  197. device supports patch caching.
  198.  ------------------------------------------------------------------------------
  199.  
  200. After some experiments I have been able to draw the following conclusions:
  201.  
  202. 1) When midiOutCache with MIDI_CACHE_BESTFIT or MIDI_CACHE_ALL then all
  203.    previously loaded patches are cleared and thus incremental patch loading
  204.    (from multiple banks, nor from a single) are not possible.
  205.  
  206. 2) The Borland Reference says nowhere that previously loaded patches should be
  207.    removed, indeed the existence of MIDI_UNCACHE and MIDI_CACHE_QUERY would
  208.    imply the contrary.
  209.    I do not have the (official) Microsoft spec. so I don't know for sure but
  210.    let's hope it's just Gravis that hasn't implemented it correctly (mistakes
  211.    can always be corrected...)
  212.  
  213. 3) If a patch, that do not exist in a bank, is requested to be cached then it
  214.    is fetched from the default bank (bank 0).
  215.  
  216. 4) Say you have loaded up some patches from bank n, then MIDI_CACHE_QUERY
  217.    will return a zero PATCHARRAY when called for all banks except bank n.
  218.    Pathes of type 3) are also reported under bank n rather than bank 0.
  219.  
  220. 5) Does anyone have any real FACTS about above?
  221.    I think/hope that one SHOULD be able to do incremental patch caching.
  222.    Maybe someone could contact Microsoft (who created the API) to find
  223.    out how it should really work.
  224.  
  225. 6) (To Gravis:) Does the UltraSound driver recognize any midiOutMessage
  226.    messages? it would be fun if there where implemented a message that
  227.    took a memory handle to a PATCHSTRUCT or something and loaded it into
  228.    GUS memory. You could do app's that loaded any patches independently
  229.    of ULTRASND.INI, you could do realtime patch editors et c. et c.
  230.  
  231. 7) Let's hope for some order in this chaos!  3 weeks to happy GUSmas everyone!
  232.  
  233. /FMJ
  234.  
  235. ------------------------------
  236.  
  237. Date: Mon, 6 Dec 1993 09:00 -0500
  238. From: WADLEIGH@PROCESS.COM
  239. Subject: Patch banking standards proposal
  240.  
  241. OK, let's make things as easy as possible.  There's already a patch banking 
  242. standard in the Roland GS.  The first step should be to retain numeric 
  243. compatibility (like the GM standard).  Now the actual implementation does NOT
  244. have to retain the restrictions of the Roland.  In that case, switching banks
  245. may have the undesired effect of switching previously-loaded patches (since it's
  246. switching ROM banks).
  247. Custom patches should be reserved for some higher bank number.  If bank #0 is
  248. the General MIDI set and bank #1 is the GS extension set, then bank #2 is the
  249. user's "permanent" development set and so on through bank #14.  Bank #15 is a 
  250. "dynamic" set.  References to bank #15 would go to an external .CFG file that 
  251. must match the file name of the MIDI file.
  252.  
  253. Did I say "simple?"  OK, so it's not easy to program and involves som new 
  254. protocols for tracking program name and .CFG files.  Its main advantage is that 
  255. it retains maximin compatibility with everything from Roland through PLAYMIDI.
  256.  
  257. More comments?
  258.  
  259. Hal
  260.  
  261. ------------------------------
  262.  
  263. From: (null)
  264.  
  265. >We have to present a case to Gravis that will allow max flexibility with
  266. >minimum fuss for the end user. (The granny test is a good one. It should be
  267. >simple enough for your grandmother to get working).
  268.  
  269. Sorry, but *NOTHING* involving a PC passes this test.  MAC, maybe.  PC, no way.
  270.  
  271. >I propose an application program be created that would be able to scan the
  272. >ULTRASND.INI file and create the bank entries for the music file you are
  273. >installing, with the correct patch names, and subdirs etc.
  274.  
  275. I would think that there ought to be a much simpler scheme.  I'm thinking of MOD 
  276. files as a model, which include the sample info directly in themselves.  One 
  277. could do something similar if we reserved a particular bank number for this 
  278. purpose (so there would be no conflicts with things the user did), and then if 
  279. there were a command that one could give to the GUS driver which said something 
  280. like "load patches into bank xxx from the following file:" and give it the path 
  281. to the file.
  282.  
  283. But anyway, this stuff is all nice, but I'd like to see static bank switching 
  284. implemented reasonably first (though one should probably keep the "ship a patch 
  285. with a song" requirement in mind while designing V1 banks.
  286.  
  287. Burns
  288.  
  289. ------------------------------
  290.  
  291. End of GUS Musician's Digest V3 #7
  292. **********************************
  293.  
  294. To post to tomorrow's digest:                        <gus-music@dsd.es.com>
  295. To (un)subscribe or get help:                <gus-music-request@dsd.es.com>
  296. To contact a human (last resort):              <gus-music-owner@dsd.es.com>
  297.  
  298. FTP sites:           archive.epas.utoronto.ca              /pub/pc/ultrasound
  299.                      wuarchive.wustl.edu            /systems/msdos/ultrasound
  300.                      archive.orst.edu                    /pub/packages/gravis
  301.                      theoris.rz.uni-konstanz.de                /pub/sound/gus
  302. FTP mail server:     mail-server@nike.rz.uni-konstanz.de
  303.  
  304. Hints:
  305.       - Get the FAQ from the FTP sites or the request server.
  306.       - Mail to <gus-music-request@dsd.es.com> for info about other
  307.     GUS related mailing lists (general use, programmers, etc.).
  308.  
  309.  
  310.